1. The Field of the Invention
The present invention relates to systems and methods for grafting the namespace of one storage medium into the namespace of another storage medium. More specifically, the present invention allows actions to performed without user or program intervention when the namespace of one storage medium is grafted into the namespace of another storage medium.
2. The Prior State of the Art
A functional computer system generally consists of three fundamental components. The first component is computer hardware, the second component is user or application programs, and the third component is an operating system. Computer hardware generally includes such devices as a central processing unit (CPU), system memory such as RAM and ROM, mass storage such as magnetic or optical disk storage, a keyboard or other input device, and a display or other output device. Users of computer systems generally interact with user or application programs. Such programs include familiar word processing applications, spreadsheet applications, database applications, and so forth. The computer operating system performs many functions such as allowing a user to initiate execution of an application program. In addition, modem operating systems also provide an interface between an application program and the computer system hardware. Thus, while it was once common place for an application program to directly access computer system hardware, modern operating systems provide standardized, consistent interfaces that allow user applications to interface with or access computer hardware in a standardized manner.
In order to provide a consistent interface between a process such as a user application and a particular type of hardware device, there may be several software layers between the actual hardware and the process. For example, a process may make a call into the operating system. The operating system, in turn, may utilize the services provided by a hardware driver layer. The hardware driver layer then interfaces directly with the hardware. A primary advantage of such a layered approach is that layers may be added or replaced without creating a huge impact on the remaining layers. For example, if a new hardware device is added to the system, a new driver may be added, which allows the operating system to access the hardware. All these changes may take place with minimal or no impact on existing application processes.
Many operating systems provide I/O subsystems that interface with various mass storage devices. Such I/O subsystems handle many details required to translate an I/O request into actions that must be performed to fill the I/O request. Many of these actions are necessitated by the required translation from a high-level concept such as retrieving information from a file into low-level actions such as positioning the read head over a particular location on a magnetic disk and retrieving information from that particular location.
In modern computer systems, data is typically stored on mass storage devices in a hierarchical fashion with directories and files organized in a hierarchy resembling a tree structure. The location of any file or directory is typically specified by a path name. The path name typically begins with a root or starting directory and names each subsequent subdirectory until the desired file or directory is reached. For example, a file called "file.dat" may be stored in a directory "temp" which is a subdirectory of the root directory "root.backslash.." To access file.dat an I/O request may include a path name, either explicitly or implicitly, which directs the I/O subsystem to a particular location in order to identify and access the appropriate file. The path name for file.dat would thus be .backslash.root.backslash.temp.backslash.file.dat.
When the I/O subsystem receives an I/O request with an associated path name, the path name must be resolved in order to allow translation to a particular location on a particular storage device so that the I/O request can be accomplished. Path names may be directly provided to the I/O subsystem or may be constructed based on known information. Resolving file names in a file system is typically a multi-stage procedure. It generally begins with a stage that decodes all of the named components that need to be successfully identified by the file system. The procedure then continues with an iterative process of identifying, usually from left to right, the successive name components of the path name. The procedure finishes with the sucess or failure of each of these name resolutions. Thus, in the example above, the path name would be broken down into successive components and the resolution process would identify, in turn, the root directory, the temp subdirectory, and the file file.dat.
With the proliferation of inexpensive powerful computers, many users and organizations are assembling networks of interconnected computers that utilize local area networks (LAN), wide area networks (WAN), or other networking technologies to allow individual users to share data and information. Often these networks of computers have multiple storage devices that can be accessed by multiple users. The result is that an individual user may have access to many different storage devices. As the number of storage devices and the hierarchy of directories and subdirectories on each storage device increases, users may have an increasingly difficult time finding and managing their data.
A volume is a storage unit that may be formatted with a file system and accessed via file system paths or device names internal to the I/O subsystem. When multiple volumes, each with a hierarchy of directories and subdirectories, are available to a user, the user may have difficulty conceptually grasping the interrelationship between the directories and subdirectories of the individual volumes. This becomes a particular problem where large amounts of data that would naturally be organized according to a particular hierarchical structure are sufficiently large to prohibit the storing and organization of all related data on a single storage volume. In such a situation, it is generally necessary to store some data on one volume and other data on other volumes. Dividing such logically related data among multiple volumes adds to the confusion and difficulty felt by some users.
To overcome some of these limitations, mechanisms have been developed to present a logical view of the storage devices that is independent of the physical organization of the data on the storage devices. These mechanisms allow the namespace of one storage device to be grafted into the namespace of another storage device so that a single coherent, logical view may be presented to a user.
Referring now to FIG. 1, an example of such a grafting process is illustrated. In FIG. 1, two volumes 20 and 22 are illustrated. Volume 20 and volume 22 each have independent directory structures. The directory structure for volume 20 is illustrated generally as 24 and the directory structure for volume 22 is illustrated generally as 26. As used herein, directory structure and namespace will be used interchangeably to identify the names or structures of directories and files on a particular volume. Although volume 20 and volume 22 each have individual directory structures, in this example it is desirable to present a single integrated directory structure to the user as illustrated by logical directory structure 28. Logical directory structure 28 illustrates that it is desirable to graft directory structure 26 into directory structure 24 at Dir4 30. When such a grafting takes place, logical directory structure 28 results.
Although many mechanisms may be used to graft the namespace of one storage volume into the namespace of another storage volume, one common technology is called a "mount point." A mount point is a namespace location where another namespace or directory structure should be mounted or grafted. Thus, in FIG. 1 Dir4 30 would be defined as a mount point. In FIG. 1 this is illustrated by dashed arrow 32. Conceptually, when mount point 30 is traversed, the file system accesses volume 22 instead of volume 20. For example, if the user is presented with logical directory structure 28, and a user wishes to access file.dat in Dir8, then the path to that file would be given as C:.backslash.Dir2.backslash.Dir4.backslash.Dir8.backslash.file.dat. When the file system resolves this path name, the file system will resolve the path name to Dir4 by accessing volume 20. Once Dir4 is accessed, however, the file system would recognize Dir4 as a mount point and continue the resolution process by accessing volume 22. In essence, a mount point traditionally acts as a sort of special directory which can redirect accesses to a location in the namespace of another volume.
Although mount points are capable of creating a logical organization that is unrelated to the underlying physical storage structure, some problems may still exist. For example, if volume 22 of FIG. 1 was a removable storage device, then before the device could be accessed via logical directory structure 28, the removable media would need to be retrieved and mounted. Typically these steps are performed prior to presenting the user with logical directory structure 28. Such a retrieval and mounting process may be initiated, for example, by a user via the operating system or by a program that knows that the device must be retrieved and mounted prior to access. Placing the burden of retrieving and mounting a removable volume on the user or on an application process yields several undesirable results. For example, users must be trained and know how to retrieve and mount the media. If the burden is placed on the application program, then each application program that wishes to retrieve and mount removable media must incorporate such functionality. This results in a great deal of redundancy and duplicated effort.
It would, therefore, be desirable to have a system which could present a logical directory structure to a user and eliminate the need for commands such as mounting and retrieval of removable storage media that must be executed before a user or application program tries to access the removable storage media. It would also be desirable to accomplish these functions without creating duplication of effort. It is further desirable to achieve this result without requiring the user to know how to retrieve and mount removable media.